昨天介紹完 Chroma 後，大家應該對向量資料庫及向量有初步的認識，接下來我們要針對向量資料庫進行詳細介紹及分析。

向量資料庫（Vector Database）

為什麼需要向量資料庫？

想像你有一個巨大的圖書館，但這個圖書館很特別：你走進去不是說「我要找書名叫 XX 的書」，而是說「我要找內容跟這本書很像的書」。傳統資料庫（像 MySQL）只會幫你做前者——精確比對，你給一個關鍵字，它幫你找一模一樣或符合條件的資料。但它完全不懂「相似」是什麼意思。

向量資料庫解決的就是這個問題。做法是：先把文字、圖片這些東西丟進 Embedding 模型（就是一個轉換器），把它們變成一串數字（向量），這串數字代表這個內容在「語意空間」中的位置。意思相近的東西，這串數字就會很接近。然後向量資料庫的工作，就是幫你快速找出「哪些數字串跟我手上這串最接近」。

為什麼不能土法煉鋼，一個一個比對就好？
因為資料一多（幾百萬、幾千萬筆），逐一比對會慢到不能用。所以向量資料庫用了一些「抄捷徑」的演算法（最紅的叫 HNSW），犧牲一點點準確度，換來速度快非常多。這就是它存在的意義。

核心概念

1. 向量是什麼？

就是一串數字。你可以想成是「座標」——把一段文字、一張圖片，丟進 Embedding 模型後，它會吐出一串數字（可能是 768 個或 1536 個），這串數字代表這段內容在「意思的空間」裡的位置。

重點是：意思相近的東西，數字會排在附近。比如「貓」跟「狗」的向量會比較靠近，「貓」跟「股票」的向量會離很遠。這就是為什麼向量資料庫能做「語意搜尋」——它找的不是文字有沒有重複，而是意思像不像。

2.怎麼算「像不像」？

有了向量之後，要有個方法算兩個向量到底有多接近，常見三種算法，白話講：

餘弦相似度：只看「方向」對不對準，不管長度。最常拿來比文字意思，因為方向代表語意主題，實務上用最多。
歐氏距離：真的算兩個點在空間中的直線距離，比較「物理」的算法。
內積：算起來最快，但前提是向量長度都要先「正規化」過（統一縮放成同一個尺度），不然結果會失真。

三種其實常常算出差不多的排名，但實務上文字語意搜尋幾乎都預設用餘弦相似度。

3. 為什麼要「近似」搜尋，而不是直接找最準的？

假設你的資料庫有一千萬筆向量，使用者丟一個問題進來，理論上最準的做法是：把這一千萬筆全部都跟使用者的向量算一次距離，再排序找出最像的幾筆。這叫暴力搜尋，準是準，但慢到爆——資料一多，使用者可能要等好幾秒甚至更久，這在實際產品上完全不能接受。

所以向量資料庫的核心技術，就是想辦法「先做一些聰明的分類跟建索引」，讓查詢的時候不用真的比對全部一千萬筆，只挑「大概率會像」的一小部分來比，這樣就能把查詢時間從秒級壓到毫秒級。代價是：找出來的答案不保證100%是「最像的那幾筆」，可能會有極少數該進榜的漏掉了，但這個誤差通常小到可以忽略——用一點點準確度換巨大的速度提升，這筆交易很划算。

常見的三種做法：

HNSW：現在最紅的做法，概念類似蓋一個「多層樓的導航地圖」，從高樓層看大方向，逐層往下縮小範圍去精確定位。速度快、準確度高，市面上主流的向量資料庫（Chroma、Weaviate、Qdrant）幾乎都用它。
IVF：先把所有向量分成很多個「群」，查詢時只挑幾個最相關的群去比對，不用全部掃過。Faiss 常用這招。
LSH：比較舊的技術，概念是設計一種特殊的雜湊函數，讓相近的向量容易被分到同一個雜湊桶裡，現在比較少人用了。

一句話總結：向量就是把「意思」變成數字座標；相似度計算是量兩個座標像不像；ANN 則是在資料量大到爆的情況下，用一點取巧的方式加速搜尋，讓系統能在毫秒內回答你。

常見向量資料庫比較

典型應用場景

• RAG（檢索增強生成）：LLM 應用最常見的用法，先檢索相關文件片段再給 LLM 生成答案
• 語意搜尋：搜尋引擎不再只靠關鍵字比對
• 推薦系統：找出相似的商品、內容
• 圖片/音訊相似搜尋：以圖搜圖、以聲搜聲
• 異常偵測：找出與正常樣本差異過大的向量

向量資料庫選型速查表

依應用情境選擇

快速決策問句

1. 資料量多大？ → 決定要不要考慮 Milvus / Pinecone 等擴展性強的方案
2. 要不要自己維運？ → 不想維運選 Pinecone；想掌控選開源方案
3. 有沒有既有系統？ → 已用 PostgreSQL 就選 pgvector，減少系統複雜度
4. 是教學/原型還是生產環境？ → 教學用 Chroma；生產視規模再決定
5. 需不需要混合搜尋？ → 需要就優先看 Weaviate